The Art of Mac Malware, Volume 2 (for caswal eraq) by Patrick Wardle

Author:Patrick Wardle
Language: eng
Format: epub
Publisher: No Starch Press

Identifying the Responsible Process

Identifying the process responsible for a DNS request is essential to detecting malware, yet DNS monitors that aren’t host-based can’t provide this information. For example, requests from trusted system processes are likely safe, while requests from, say, a persistent, unnotarized process such as iWebUpdate should be closely scrutinized.

Now I’ll show you how to obtain the ID of the responsible process using information provided by the NetworkExtension framework. The flow object passed into the extension via the handleNewFlow: delegate method contains an instance variable named metaData whose type is NEFlowMetaData. Consulting the NEFlowMetaData.h file (found in NetworkExtension.framework/Versions/A/Headers/) reveals that it contains a property named sourceAppAuditToken with the responsible process’s audit token.

From this audit token, we can extract the responsible process’s ID and securely obtain its path using SecCode* APIs. Listing 7-9 implements this technique.

CFURLRef path = NULL; SecCodeRef code = NULL; audit_token_t* auditToken = (audit_token_t*)flow.metaData.sourceAppAuditToken.bytes; ❶ pid_t pid = audit_token_to_pid(*auditToken); ❷ SecCodeCopyGuestWithAttributes(NULL, (__bridge CFDictionaryRef _Nullable)(@{(_bridge NSString*)kSecGuestAttributeAudit:flow.metaData.sourceAppAuditToken}), kSecCSDefaultFlags, &code); ❸ SecCodeCopyPath(code, kSecCSDefaultFlags, &path); ❹ // Do something with the process ID and path. CFRelease(path); CFRelease(code);

Listing 7-9: Obtaining the responsible process’s ID and path from a network flow

First, we initialize a pointer to an audit token. As noted, the sourceAppAuditToken contains this token in the form of an NSData object. To get a pointer to the audit token’s actual bytes, we use the bytes property of the NSData class ❶. With this pointer, we can extract the associated process ID via the audit_token_to_pid function ❷. Next, we obtain a code reference from the audit token ❸ and then invoke the SecCodeCopyPath function to obtain the process’s path ❹.

It’s worth noting that the SecCodeCopyGuestWithAttributes API can fail, for example, if the process has self-deleted. This case is both very unusual and likely indicative of a malicious process. Regardless, you’ll have to defer to other, less certain methods of obtaining the process’s path, such as examining the process’s arguments, which can be surreptitiously modified.

From the flow, we can also extract the responsible process’s code signing identifier, which can help classify the process as either benign or something to investigate further. This identifier is in the flow’s sourceAppSigningIdentifier attribute. Listing 7-10 extracts it.

NSString* signingID = flow.metaData.sourceAppSigningIdentifier;

Listing 7-10: Extracting code signing information from a network flow

As noted earlier in this chapter, the DNS monitoring process I’ve described thus far would fail to detect malware such as Dummy, which connects directly to an IP address. To detect such threats, let’s expand our monitoring capabilities to examine all network traffic.

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.